Towards User-Defined Relations
Christoph Höger
christoph.hoeger@tu-berlin.de
04.02.2013 - Openmodelica Workshop 2013

Agenda
-
What is a user-defined relation?
Short overview and problem description.
-
How can we get user-defined relations?
What semantic problems need to be solved inside an implementation.
-
What works today?
Relations as first-class citizens.
-
What next?
Defining relation-resolution
Problem Scope
Current situation
-
Models are composed by relations.
Usually connect, but also branch, transition (so called Equation Operators)
-
The global set of all relations implies a set of equations.
Actually, they are computed according to some algorithms defined in the language spec.
-
This process may introduce some symbols
E.g. isRoot, they can only be used in equations!
The Specification's Issue With Connection Semantics
-
Five Different connection semantics do already exist.
These are: Potential/Flow/Stream/Overconstrained/Transitions. More are likely to come.
-
Partially defined in pseudo-code (stream)
This is, in general, a good thing. Unfortunately they cannot be expressed in actual, valid Modelica.
-
Partially defined in algorithmically
E.g. overconstrained connectors. Again, this is a good thing.

The User's/Implementor's Issue With Connection Semantics
-
Hard to extend
You want a new kind of connection? Go write a Specification chapter!
-
Hard to test
Is there a contradiction between e.g. the stream semantics and some of the newer additions to the language? Who knows?
Hard to implement
Have you ever tried to just understand the concept of stream in one day as a programmer?
The Implementor's Solution
-
Describe this process by code
Ideally, an engineer should do it, not a programmer!
-
(Specification benefit)
Ship this code as a core library.
What do we need?
Steps needed
-
Lift variables to the object level.
A Real is not just a number, but an unknown! It can be evaluated like anything else.
-
Lift relations to the object level.
Relations are basically named records. Records are (hopefully) already implemented in $TOOL
-
Compute equations out of the relation-sets
How to do this leaves many degrees of freedom.
Variables as objects
Equality can be computed on variables, since they are globally named!
OpenModelica's current answer
Warning: In componentRelations as objects
connect(x,y);Ideally, we could represent a relation as a special data structure in Modelica:
Syntax compatible extension
connect(x,y);Unfortunately, we do not have that currently.
This record is like a model, except it cannot be constructed implicitly.
Evaluate relations like records
[/tmp/X.mo:7:18-7:20:writable] Error: No viable alternative near token: ifEquivalent rewrite
They should be the same!
Demo: What works now
Simple Example
Calculating Connected Sets
(Using External Java functions)
Calculating Equations
(More or less Modelica)
Result (no flows yet)
- .R1.n.u = .source.p.u
- .R1.p.u = .C1.n.u
- .I1.n.u = .C1.p.u
- .source.n.u = .ground.p.u
- .I1.p.u = .source.n.u
- ...
There would have been a demo...

Calculating Equations differently
(Equivalent formulation)
Result (no flows yet)
- (-1,000000 * .R1.n.u) + (1,000000 * .source.p.u) = 0,000000
- (-1,000000 * .C1.n.u) + (1,000000 * .R1.p.u) = 0,000000
- (-1,000000 * .I1.n.u) + (1,000000 * .C1.p.u) = 0,000000
- (-1,000000 * .I1.p.u) + (1,000000 * .ground.p.u) = 0,000000
- (-1,000000 * .ground.p.u) + (1,000000 * .source.n.u) = 0,000000
- ...
Future
Resolution of relations
Create equations based on computation.
This is actually, what models usually are good for.
Make general purpose data structures available
This requires a better FFI
Define a calling convention.
This requires a lot of discussions.
/
← →